Internet Info 1994 March

home *** CD-ROM | disk | FTP | other *** search

/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / internet-drafts / draft-ietf-tn3270e-enhancements-00.txt < prev next >

Wrap

Text File | 1993-07-26 | 64.5 KB | 1,596 lines

TN3270 Enhancements Working Group B. Kelly Internet Draft Auburn University July 1993 TN3270 Enhancements Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress." Please check the 1id-abstracts.txt listing contained in the internet-drafts Shadow Directories on ds.internic.net, nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the current status of any Internet Draft. Abstract This document describes a protocol that more fully supports 3270 devices than do the existing tn3270 practices. Specifically, it defines a method of emulating both the terminal and printer members of the 3270 family of devices via Telnet; it provides for the ability of a Telnet client to request that it be assigned a specific device-name (also referred to as "LU name" or "network name"); finally, it adds support for a variety of functions such as the ATTN key, the SYSREQ key, and SNA response handling. This protocol would be negotiated and implemented under a new Telnet Option and would be unrelated to the Telnet 3270 Regime Option as defined in RFC 1041 [1]. B. Kelly Expires January 1994 [Page 1] Internet Draft TN3270 Enhancements July 1993 TABLE OF CONTENTS 1. INTRODUCTION ............................................... 2 2. TN3270E OVERVIEW ........................................... 3 3. COMMAND NAMES AND CODES .................................... 4 4. COMMAND MEANINGS ........................................... 5 5. DEFAULT SPECIFICATION ...................................... 6 6. MOTIVATION ................................................. 6 7. IMPLEMENTATION RULES ....................................... 7 7.1 DEVICE-TYPE Negotiation ................................ 7 7.2 FUNCTIONS Negotiation .................................. 11 8. TN3270E DATA MESSAGES ...................................... 13 8.1 The TN3270E Message Header ............................. 13 8.1.1 DATA-TYPE Field ................................... 14 8.1.2 REQUEST-FLAG Field ................................ 14 8.1.3 RESPONSE-FLAG Field ............................... 15 9. BASIC TN3270E .............................................. 16 10. DETAILS OF PROCESSING TN3270E FUNCTIONS .................... 17 10.1 The SCS-CTL-CODES Function ............................. 17 10.2 The DATA-STEAM-CTL Function ............................ 18 10.3 The BIND-IMAGE Function ................................ 18 10.4 The RESPONSE Function .................................. 19 11. THE 3270 ATTN KEY .......................................... 21 12. THE 3270 SYSREQ KEY ........................................ 22 13. 3270 STRUCTURED FIELDS ..................................... 23 14. EXAMPLES ................................................... 24 15. REFERENCES ................................................. 26 16. AUTHOR'S NOTE .............................................. 26 17. AUTHOR'S ADDRESS ........................................... 27 1. Introduction Currently, support for 3270 terminal emulation over Telnet is accomplished by the de facto standard of negotiating three separate Telnet Options - Terminal-Type [2], Binary Transmission [3], and End of Record [4]. Note that there is no RFC that specifies this negotiation as a standard. RFC 1041 attempted to standardize the method of negotiating 3270 terminal support by defining the 3270 Regime Telnet Option. Unfortunately, very few developers and vendors ever implemented RFC 1041. This document will refer to the existing practice of negotiating these three Telnet Options before exchanging the 3270 data stream as "traditional tn3270". NOTE: Except where otherwise stated, this document does not distinguish between Telnet servers that represent SNA devices and those that represent non-SNA 3270 devices. All references in this document to the 3270 data stream, SNA versus non-SNA operation, 3270 data stream commands, orders, structured B. Kelly Expires January 1994 [Page 2] Internet Draft TN3270 Enhancements July 1993 fields and the like rely on [5]. References to SNA Request and Response Units rely on [6]. There are several shortcomings in traditional tn3270; among them are the following: - It provides no capability for Telnet clients to emulate the 328x class of printers. - There is no mechanism by which a Telnet client can request that a connection be associated with a given 3270 device-name. This can be of importance when a terminal session is being established, since many host applications behave differently depending on the network name of the terminal. In the case of printer emulation, this capability is an absolute necessity because a large number of host applications have some method of pre-defining printer destinations. - The 3270 ATTN and SYSREQ keys are not universally supported. - There is no support for the SNA positive/negative response process. This is particularly important if printer emulation is to function properly, but is also useful for some terminal applications. A positive response is used to indicate that the previously received data has been successfully processed. A negative response indicates some sort of error at the client while processing the previously received data; this could be caused by the host application building a 3270 data stream that contains an invalid command, or by a mechanical error at the client side, among other things. - There is no mechanism by which the client can access the SNA BIND information. The BIND image contains a detailed description of the session between the Telnet server and the host application. - There is no mechanism by which the server can determine whether a client supports 3270 structured fields, or a client can request that it receive them. 2. TN3270E Overview In order to address these issues, this document proposes a new Telnet Option - TN3270E (option number has yet to be assigned). Telnet clients and servers would be free to negotiate support of the TN3270E option or not. If either side does not support TN3270E, traditional tn3270 can be used; otherwise, a sub-negotiation will occur to determine what subset of TN3270E will be used on the session. It is anticipated that a client or server capable of both types of 3270 emulation would attempt to negotiate TN3270E first, B. Kelly Expires January 1994 [Page 3] Internet Draft TN3270 Enhancements July 1993 and only negotiate traditional tn3270 if the other side refuses TN3270E. Once a client and server have agreed to use TN3270E, negotiation of the TN3270E suboptions can begin. The two major elements of TN3270E sub-negotiation are: - a device-type negotiation that is similar to, but somewhat more complicated than, the existing Telnet Terminal-Type Option. - the negotiation of a set of supported 3270 functions, such as printer data stream type (3270 data stream or SNA Character Stream), positive/negative response exchanges, device status information, and the passing of BIND information from server to client. Successful negotiation of these two suboptions signals the beginning of 3270 data stream transmission. In order to support several of the new functions in TN3270E, each data message must be prefixed by a header. This header will contain flags and indicators that convey such things as positive and negative responses and what type of data follows the header (for example, 3270 data stream, SNA Character Stream, or device status information). 3. Command Names and Codes TN3270E (to be assigned) ASSOCIATE 00 CONNECT 01 DEVICE-TYPE 02 FUNCTIONS 03 IS 04 REASON 05 REJECT 06 REQUEST 07 SEND 08 Reason-codes CONN-PARTNER 00 DEVICE-IN-USE 01 INV-ASSOCIATE 02 INV-DEVICE-NAME 03 INV-DEVICE-TYPE 04 TYPE-NAME-ERROR 05 UNKNOWN-ERROR 06 UNSUPPORTED-REQ 07 B. Kelly Expires January 1994 [Page 4] Internet Draft TN3270 Enhancements July 1993 Function Names BIND-IMAGE 00 DATA-STREAM-CTL 01 RESPONSES 02 SCS-CTL-CODES 03 4. Command Meanings IAC WILL TN3270E The sender of this command is willing to send TN3270E information in subsequent sub-negotiations. IAC WON'T TN3270E The sender of this command refuses to send TN3270E information. IAC DO TN3270E The sender of this command is willing to receive TN3270E information in subsequent sub-negotiations. IAC DON'T TN3270E The sender of this command refuses to receive TN3270E information. Note that while they are not explicitly negotiated, the equivalent of the Telnet Binary Transmission Option [3] and the Telnet End of Record Option [4] is implied in the negotiation of the TN3270E Option. That is, a party to the negotiation that agrees to support TN3270E is automatically required to support bi-directional binary and EOR transmissions. IAC SB TN3270E SEND DEVICE-TYPE IAC SE Only the server may send this command. This command is used to request that the client transmit a device-type and, optionally, device-name information. IAC SB TN3270E DEVICE-TYPE REQUEST <device-type> [CONNECT | ASSOCIATE <device-name>] IAC SE Only the client may send this command. It is used in response to the server's SEND DEVICE-TYPE command, as well as to suggest another device-type after the server has sent a DEVICE-TYPE REJECT command (see below). This command requests emulation of a specific 3270 device type and model. The REQUEST command may optionally include either the CONNECT or the ASSOCIATE command (but not both). If present, CONNECT and ASSOCIATE must both be B. Kelly Expires January 1994 [Page 5] Internet Draft TN3270 Enhancements July 1993 followed by <device-name>. (See the section entitled "Implementation Rules" for more detailed information.) IAC SB TN3270E DEVICE-TYPE IS <device-type> CONNECT <device-name> IAC SE Only the server may send this command. This command is used to accept a client's DEVICE-TYPE REQUEST command. IAC SB TN3270E DEVICE-TYPE REJECT REASON <reason-code> IAC SE Only the server may send this command. This command is used to reject a client's DEVICE-TYPE REQUEST command. IAC SB TN3270E FUNCTIONS REQUEST <function-list> IAC SE Either side may send this command. This command is used to suggest a set of 3270 functions that will be supported on this session. It is also sent as an implicit rejection of a previous FUNCTIONS REQUEST command sent by the other side (see the section entitled "Implementation Rules" for more information). Note that when used to reject a FUNCTIONS REQUEST command, the function-list must not be identical to that received in the previous REQUEST command. IAC SB TN3270E FUNCTIONS IS <function-list> IAC SE Either side may send this command. This command is sent as a response to a FUNCTIONS REQUEST command and implies acceptance of the set of functions sent to it in the REQUEST command. Note that the list of functions in the FUNCTIONS IS command must match the list that was received in the previous FUNCTIONS REQUEST command. 5. Default Specification WON'T TN3270E DON'T TN3270E i.e., TN3270E will not be used. 6. Motivation See the section entitled "Introduction." B. Kelly Expires January 1994 [Page 6] Internet Draft TN3270 Enhancements July 1993 7. Implementation Rules All TN3270E commands and parameters are NVT ASCII strings in which upper and lower case are considered equivalent. Once it has been agreed that TN3270E will be supported, the first sub-negotiation must concern the DEVICE-TYPE (and possibly DEVICE-NAME) information. Only after that has been successfully negotiated can the client and server exchange FUNCTIONS information. Only after both DEVICE-TYPE and FUNCTIONS have been successfully negotiated can 3270 data stream transmission occur. 7.1 DEVICE-TYPE Negotiation Device-type (and device-name) negotiation begins when the server transmits the DEVICE-TYPE SEND command to the client. The client responds with the DEVICE-TYPE REQUEST command, which must include a device-type and may include a device-name request. Valid device-types are: terminals: IBM-3278-2-E IBM-3278-3-E IBM-3278-4-E IBM-3278-5-E IBM-3279-2-E IBM-3279-3-E printers: IBM-3287-1 An explanation of the CONNECT and ASSOCIATE commands first requires a discussion of the organization of terminal and printer device pools that the server maintains and from which it selects device-names to assign to session requests. (The terms "device-name", "LU name" and "network name" can be considered interchangeable in this document.) Also, for the purposes of this discussion, the term "generic session request" will be used to describe a request for a session from a Telnet client (either traditional or TN3270E) that does not include a request for a specific device-name. The term "specific session request" will be used to describe a request for a session from a TN3270E client that includes a request for a specific device-name (either via CONNECT or ASSOCIATE). As is the case with traditional tn3270, the TN3270E server must maintain a set of terminal device-names. A generic request for a terminal session would result in the server selecting any availabe device-name from this pool. The server, however, may also maintain a separate pool of terminal device-names which can only be used to satisfy specific terminal session requests. This is to ensure that a terminal device that has some B. Kelly Expires January 1994 [Page 7] Internet Draft TN3270 Enhancements July 1993 significance to host applications (and is therefore likely to be the target of a specific session request) is not "accidentally" assigned to a generic request and winds up associated with a client that has no use for it. Note that the reverse situation is allowed. That is, a specific terminal session request could ask for a device-name that happens to be in the "generic terminal pool." For each terminal device (in both the "generic" and the "specific" pools), the TN3270E server could also have defined a "partner" or "paired" printer device. There should be a unique, one-to-one mapping between a terminal and its associated printer. The reasoning behind such a configuration is to allow for those host applications that produce printed output bound for a printer whose device-name is determined by the device-name of the terminal that initiated the print request. These printer devices can only be assigned to specific printer session requests that use the ASSOCIATE command (see below). In addition, the TN3270E server may also maintain a pool of printer device-names that are not associated with any terminal. These printer devices can only be assigned to specific printer session requests that use the CONNECT command (see below). This allows for those host applications that generate printed output bound for a printer whose device-name is determined by something other than the device-name of the terminal that initiated the print request (for example, when the userid of the person signed on to a terminal determines the print destination). Finally, it is possible that a pool of printer device-names could be maintained and used only to satisfy generic requests for printers. CONNECT is used by the client to request that the server assign a specific device-name to this Telnet session; it may be used when requesting either a terminal or a printer session. The specified device-name must not conflict with the device-type; e.g., if the client requests DEVICE-TYPE IBM-3287-1 (a printer) and specifies CONNECT T1000001, but T1000001 is defined at the host as a terminal, then the server should deny the request. Further, if the requested device-name is already associated with some other Telnet session, or if it is not defined to the server, the server should deny the request. ASSOCIATE can be used by the client only when requesting a DEVICE-TYPE that represents a printer. The ASSOCIATE command requests that this session be assigned the device-name of the printer that is paired with the terminal named in the request. If the device-type does not represent a printer, or if the device-name is not that of a terminal, then the server should deny the request. It is anticipated that the device-name B. Kelly Expires January 1994 [Page 8] Internet Draft TN3270 Enhancements July 1993 specified in this request would be one returned by the server when accepting a previous terminal session request (see the IS command below). Since no means of authentication has been provided for, it is possible that the printer paired with the terminal specified in the ASSOCIATE command has already been assigned to some other Telnet session; in this case, the server should deny the request. To summarize, assume a TN3270E server has the following device pools defined to it (device-names that begin with a "T" are terminal devices; those that begin with a "P" are printers): Generic Terminal Pool Specific Terminal Pool --------------------- ---------------------- TG000001 <--> PTG00001 TS000001 <--> PTS00001 TG000002 <--> PTG00002 TS000001 <--> PTS00002 TG000003 <--> PTG00003 TS000001 <--> PTS00003 Generic Printer Pool Specific Printer Pool -------------------- ---------------------- PG000001 PS000001 PG000002 PS000002 PG000003 PS000003 Note that the only pool that absolutely must be defined to the server is the generic terminal pool. The absence of other pools (or of partner printers for a terminal pool) simply means that the server is unable to satisfy as wide a variety of requests as would be possible if all pools were defined to it. Given the above configuration, the following rules apply: - a generic terminal request can only be satisfied from the generic terminal pool (device-names TG000001 - TG000003). - a specific terminal request (allowable only via the CONNECT command) can be satisfied from either the generic or the specific terminal pool, although it is anticipated that the majority of such requests would ask for terminals in the specific terminal pool (TS000001 - TS000003). - a generic printer request can only be satisfied from the generic printer pool (device-names PG000001 - PG000003). - a specific printer request may come in one of two forms: via ASSOCIATE: the request can only be satisfied using the partner of the specified terminal, which may be in the generic or the specific terminal pool; therefore, devices in the B. Kelly Expires January 1994 [Page 9] Internet Draft TN3270 Enhancements July 1993 ranges PTG00001 - PTG00003 and PTS00001 - PTS00003 can be used to satisfy the request. via CONNECT: the request can be satisfied either from the generic or the specific printer pools (although, as with specific terminal requests, it is likely that most such requests will name printers in the specific printer pool); this request cannot be satisfied with the partner printer of a terminal in either the specific or the generic terminal pools. The server must accept the client's request or deny it as a whole - it cannot, for example, accept the DEVICE-TYPE request but deny the CONNECT portion. If the server wishes to accept the request, it sends back the DEVICE-TYPE IS command confirming the requested device-type and the CONNECT command specifying the device-name of the terminal or printer assigned to this Telnet session. This device-name may be the one directly requested (via CONNECT) by the client, the one indirectly requested (via ASSOCIATE) by the client, or one chosen by the server if the client specified neither CONNECT nor ASSOCIATE. If the server wishes to deny the request, it sends back the DEVICE-TYPE REJECT command with one of the following reason-codes: Reason code name Explanation ---------------- ----------------------------------- INV-DEVICE-TYPE The server does not support the requested device-type. INV-DEVICE-NAME The device-name specified in the CONNECT or ASSOCIATE command is not known to the server. DEVICE-IN-USE The requested device-name is already associated with another Telnet session. TYPE-NAME-ERROR The requested device-name is incompatible with the requested device-type (such as terminal/ printer mismatch). UNSUPPORTED-REQ The server is unable to satisfy the type of request sent by the client; e.g., a specific terminal or printer was requested but the B. Kelly Expires January 1994 [Page 10] Internet Draft TN3270 Enhancements July 1993 server does not have such a pool of device-names defined to it, or the ASSOCIATE command was used but no partner printers are defined to the server. INV-ASSOCIATE The client used the ASSOCIATE command and either the device-type is not a printer or the device-name is not a terminal. CONN-PARTNER The client used the CONNECT command to request a specific printer but the device-name requested is the partner to some terminal. UNKNOWN-ERROR Any other error in device type or name processing has occurred. The process of negotiating a device-type and device-name that are acceptable to both client and server may entail several iterations of DEVICE-TYPE REQUEST and DEVICE-TYPE REJECT commands. The client should make use of the reason-code specified by the server in any DEVICE-TYPE REJECT command(s) to minimize the amount of negotiation necessary. For example, if the client initially requests that it be assigned a specific terminal device-name via the CONNECT command, and the server rejects the request with a reason-code of UNSUPPORTED-REQ, the client should make no further specific terminal requests in the negotiations. If at any point in the process either side wishes to "bail out," it can simply send a WON'T (or DON'T) TN3270E command to the other side. At this point both sides are free to negotiate other Telnet options (including traditional tn3270). 7.2 FUNCTIONS Negotiation Once the DEVICE-TYPE negotiation has successfully completed (i.e, when the client receives the DEVICE-TYPE IS command), the client should initiate the FUNCTIONS negotiation by sending the FUNCTIONS REQUEST command to the server. After this initial REQUEST command, both sides are free to transmit FUNCTIONS REQUEST and FUNCTIONS IS commands as needed. The FUNCTIONS REQUEST command contains a list of the 3270 functions that the sender would like to see supported on this session. All functions not in the list are to be considered unsupported. The function-list consists of a string of 2-byte entries separated from one another by a single space character. The list is terminated by the IAC code that precedes the SE command. Functions may appear in any order in the list. B. Kelly Expires January 1994 [Page 11] Internet Draft TN3270 Enhancements July 1993 Upon receipt of a FUNCTIONS REQUEST command, the recipient has two choices: - it may respond in the positive (meaning it agrees to support all functions in the list, and not to transmit any data related to functions not in the list). To do this, it sends the FUNCTIONS IS command with the function-list exactly as it was received. At this point, FUNCTIONS negotiation has successfully completed. - it may respond in the negative by sending a FUNCTIONS REQUEST command in which the function-list differs from the one it received (and not simply in the order of appearance of functions in the list; at least one function must have been added to, or removed from, the list). To avoid endlessly looping, neither party should add to the function-list it receives any function that it has previously added and that the other side has removed. The process of sending FUNCTIONS REQUEST commands back and forth continues until one side receives a function-list it is willing to live with. It uses the FUNCTIONS IS command to accept the list, and, once this command is received by the other side, all necessary negotiation has been completed. At this point, 3270 data stream transmission can begin. Note that it is possible that the function-list agreed to is null; this is referred to as "basic TN3270E." See the section entitled "Basic TN3270E" for more information. The following list briefly describes the 3270 functions that may be negotiated in the function-list: Function Name Description ------------- ----------- SCS-CTL-CODES (Printer sessions only). Allows the use of the SNA Character Stream (SCS) and SCS control codes on the session. SCS is used with LU type 1 SNA sessions. DATA-STREAM-CTL (Printer sessions only). Allows the use of the standard 3270 data stream. This corresponds to LU type 3 SNA sessions. DATA-STREAM-CTL is mutually exclusive with SCS-CTL-CODES (only one of these should appear in a function-list). RESPONSES Provides support for positive and negative response handling. Allows the B. Kelly Expires January 1994 [Page 12] Internet Draft TN3270 Enhancements July 1993 server to reflect to the client any and all definite, exception, and no response requests sent by the host application. BIND-IMAGE Allows the server to send (upon request) the SNA BIND image to the client. See the section entitled "Details of Processing TN3270E Functions" for a more detailed explanation of the meaning and use of these functions. 8. TN3270E Data Messages 3270 device communications are generally understood to be block oriented in nature. That is, each partner buffers data until an entire "message" has been built, at which point the data is sent to the other side. The "message" consists of a series of 3270 commands, buffer orders, buffer addresses, and data. The end of a message is understood to be the last byte transmitted (note that this discussion disregards SNA chaining). The Telnet EOR command is used to delimit these natural 3270 blocks of data within the Telnet data stream. In TN3270E, each 3270 message must be prefixed with a TN3270E header, which consists of four bytes and whose format is defined below (see the section entitled "The TN3270E Message Header"). A "data message" in TN3270E therefore has the following construction: <TN3270E Header><data><IAC EOR> It should be noted that it is possible that, for certain message types, there is no data portion present. In this case, the TN3270E data message consists of: <TN3270E Header><IAC EOR> Note also that Telnet commands may appear anywhere in the Telnet stream. For this reason, if either side wishes to transmit the decimal value 255 and have it interpreted as data, it must "double" this byte. In other words, a single occurance of decimal 255 will be interpreted by the other side as an IAC, while two successive bytes containing decimal 255 will be treated as one data byte with a value of decimal 255. 8.1 The TN3270E Message Header As stated earlier, each data message in TN3270E must be prefixed B. Kelly Expires January 1994 [Page 13] Internet Draft TN3270 Enhancements July 1993 by a header, which consists of four bytes and is formatted as follows: ------------------------------------------------ | DATA-TYPE | REQUEST-FLAG | RESPONSE-FLAG | ------------------------------------------------ 2 bytes 1 byte 1 byte 8.1.1 DATA-TYPE Field The DATA-TYPE field indicates how the data portion of the message is to be interpreted by the receiver. Possible values for the DATA-TYPE field are: Data-type Name Code Meaning -------------- ---- --------------------------------- 3270-DATA 00 The data portion of the message contains only the 3270 data stream. SCS-DATA 01 The data portion of the message contains SNA Character Stream data. RESPONSE 02 The data portion of the message constitutes device-status information and the RESPONSE-FLAG field indicates whether this is a postive or negative response (see below). BIND-IMAGE 03 The data portion of the message is the SNA bind image from the session established between the server and the host application. NVT-DATA 04 The data portion of the message is to be interpreted as NVT data. REQUEST 05 There is no data portion present in the message. Only the REQUEST-FLAG field has any meaning. 8.1.2 REQUEST-FLAG Field The REQUEST-FLAG field only has meaning when the DATA-TYPE field has a value of REQUEST; otherwise, the REQUEST-FLAG field must be ignored by the receiver and should be set to 0x00 by the sender. Possible values for the REQUEST-FLAG field are: B. Kelly Expires January 1994 [Page 14] Internet Draft TN3270 Enhancements July 1993 Request-Flag Name Code Meaning ----------------- ---- --------------------------------- SEND-BIND 0 The client wishes the server to send a copy of the SNA bind image used to establish a session between the host application and the server. BIND-UNAVAILABLE 1 The server sends this to the client if it has received a SEND-BIND request from the client, but there is no bind image to send. ERR-COND-CLEARED 2 The client sends this to the server when some previously encountered printer error condition has been cleared. (See the section entitled "The RESPONSE Function" below.) 8.1.3 RESPONSE-FLAG Field The RESPONSE-FLAG field only has meaning for certain values of the DATA-TYPE field. For DATA-TYPE field values of 3270-DATA and SCS-DATA, the RESPONSE-FLAG is an indication of whether or not the sender of the data expects to receive a response. In this case the possible values of RESPONSE-FLAG are: Response-Flag Name Code Meaning ------------------ ---- --------------------------------- NO-RESPONSE 0 The sender does not expect the receiver to respond either positively or negatively to this message. ERROR-RESPONSE 1 The sender only expects the receiver to respond to this message if some type of error occurred, in which case a negative response is expected. ALWAYS-RESPONSE 2 The sender expects the receiver to respond negatively if an error occurs, or positively if no errors occur. For a DATA-TYPE field value of RESPONSE, the RESPONSE-FLAG is an actual response to the previous data message (which must by definition have had a DATA-TYPE of either 3270-DATA or SCS-DATA and a RESPONSE-FLAG value of either ERROR-RESPONSE or ALWAYS-RESPONSE). In this case the possible values of RESPONSE-FLAG are: B. Kelly Expires January 1994 [Page 15] Internet Draft TN3270 Enhancements July 1993 Response-Flag Name Code Meaning ------------------ ---- --------------------------------- POSITIVE-RESPONSE 0 The previous message was received and executed successfully with no errors. NEGATIVE-RESPONSE 1 The previous message was received but an error(s) occurred while processing it. Accompanying device status information will be found in the data portion of the message. For any other values of the DATA-TYPE field, the RESPONSE-FLAG field must be ignored by the receiver and should be set to 0x00 by the sender. 9. Basic TN3270E As has been stated earlier, whether or not the use of each of the TN3270E functions is allowed on a session is negotiated when the connection is established. It is possible that none of the functions are agreed to (in this case, the function-list in the FUNCTIONS REQUEST and FUNCTIONS IS commands is null). This mode of operation is referred to as "basic TN3270E." Note that, since neither SCS-CTL-CODES nor DATA-STREAM-CTL is negotiated, basic TN3270E refers to terminal sessions only. Basic TN3270E requires the support of only the following TN3270E header values: Header field Value ------------ ----- DATA-TYPE 3270-DATA DATA-TYPE SCS-DATA DATA-TYPE NVT-DATA At any given time, a TN3270E connection can be considered to be operating in either "3270 mode" or "NVT mode." In 3270 mode, each party may send data messages with the DATA-TYPE flag set to either 3270-DATA or SCS-DATA (SCS-DATA is used only in support of the SYSREQ key); sending a DATA-TYPE flag set to NVT-DATA constitutes a request to switch modes. In NVT mode, each party may send data messages with the DATA-TYPE flag set to NVT-DATA; sending 3270-DATA or SCS-DATA is a request to switch modes. The connection is initially in 3270 mode when TN3270E operation is successfully negotiated. When a party receives a message with a DATA-TYPE different from the mode it is operating in, the mode of operation for the connection is switched. Switching modes results in the client performing the equivalent of a 3270 Erase/Reset operation, as described in [5], using the default partition size. The server B. Kelly Expires January 1994 [Page 16] Internet Draft TN3270 Enhancements July 1993 cannot assume the client preserves any attributes of the previous environment across a mode switch. Typically, NVT data is used by a server to interact with the user of a client. It allows the server to do this using a simple NVT data stream, instead of requiring a 3270 data stream. An example would be a server which displays a list of 3270 applications to which it can connect the client. The server would use NVT data to display the list and read the user's choice. Then the server would connect to the application, and begin the exchange of 3270 data between the application and the client. The REQUEST-FLAG and RESPONSE-FLAG fields are not used in basic TN3270E. 10. Details of Processing TN3270E Functions Agreement by both parties to a specific function in the FUNCTIONS REQUEST function-list implies agreement by each party to support a related set of values in the TN3270E header. It also implies a willingness to adhere to the rules governing the processing of data messages as regards the agreed upon function. Either party that fails to accept header values associated either with agreed upon functions or with basic TN3270E, or attempts to use header values associated with a function that is not a part of basic TN3270E and was not agreed upon, will be considered non-conforming and in violation of the protocol. The following sections detail for each TN3270E function the associated header values and processing rules. 10.1 The SCS-CTL-CODES Function This function can only be supported on a 3270 printer session. If either party receives this function in a FUNCTIONS REQUEST function-list when the previously negotiated device-type represents a terminal, it must remove the SCS-CTL-CODES function from the list before responding with a FUNCTIONS REQUEST of its own. Either SCS-CTL-CODES or DATA-STREAM-CTL must be agreed to by both parties when the negotiated device-type represents a printer. Agreement to support this function requires that the party support the following TN3270E header values: Header field Value ------------ ----- DATA-TYPE SCS-DATA When SCS-CTL-CODES is in effect, neither side should send a data message with a DATA-TYPE of 3270-DATA. B. Kelly Expires January 1994 [Page 17] Internet Draft TN3270 Enhancements July 1993 10.2 The DATA-STREAM-CTL Function This function can only be supported on a 3270 printer session. If either party receives this function in a FUNCTIONS REQUEST function-list when the previously negotiated device-type represents a terminal, it must remove the DATA-STREAM-CTL function from the list before responding with a FUNCTIONS REQUEST of its own. Agreement to support this function requires that the party support the following TN3270E header values: Header field Value ------------ ----- DATA-TYPE 3270-DATA When DATA-STREAM-CTL is in effect, neither side should send a data message with a DATA-TYPE of SCS-DATA. 10.3 The BIND-IMAGE Function This function can only be supported when the TN3270E server represents SNA terminals and printers. Agreement to support this function requires that the party support the following TN3270E header values: Header field Value ------------ ----- DATA-TYPE BIND-IMAGE DATA-TYPE REQUEST REQUEST-FLAG SEND-BIND REQUEST-FLAG BIND-UNAVAILABLE At any point after support of the BIND-IMAGE function has been agreed upon, the client may send a data message to the server in which the header DATA-TYPE field is set to REQUEST, and the header REQUEST-FLAG is set to SEND-BIND. There is no data portion in this message. If an SNA session exists between the server and a host application on behalf of the client, the server must respond with a data message in which the header DATA-TYPE field is set to BIND-IMAGE and the data portion of the message consists solely of the exact image of the SNA bind that was used to establish that SNA session. If the server has no session established with a host application on behalf of the client when it receives the SEND-BIND request, it should send a data message to the client in which the header DATA-TYPE field is set to REQUEST and the header REQUEST-FLAG is set to BIND-UNAVAILABLE. B. Kelly Expires January 1994 [Page 18] Internet Draft TN3270 Enhancements July 1993 10.4 The RESPONSE Function This function can be supported for both terminal and printer sessions connected to both SNA and non-SNA servers. Agreement to support this function requires that the party support the following TN3270E header values: Header field Value ------------ ----- DATA-TYPE RESPONSE DATA-TYPE REQUEST RESPONSE-FLAG -all values- REQUEST-FLAG ERR-COND-CLEARED When the RESPONSE function is in effect, each party must adhere to the following rules: - Whenever a data message is sent with a DATA-TYPE of either SCS-DATA or 3270-DATA, the sender must set the RESPONSE-FLAG field to either NO-RESPONSE, ERROR-RESPONSE, or ALWAYS-RESPONSE. It is anticipated that the client side will normally set RESPONSE-FLAG to NO-RESPONSE. The server, if it represents an SNA device, should set RESPONSE-FLAG to reflect the response value set in the RH of the RU that generated this data message - Definite Response resulting in a RESPONSE-FLAG value of ALWAYS-RESPONSE, Exception Response resulting in ERROR-RESPONSE being set, and No Response causing a setting of NO-RESPONSE. A non-SNA server should set RESPONSE-FLAG to ERROR-RESPONSE. - Whenever a data message with a DATA-TYPE of either SCS-DATA or 3270-DATA is received, the receiver must attempt to process the data in the data portion of the message, then determine whether or not it should send a data message with a DATA-TYPE of RESPONSE. If the data message it has just processed had a RESPONSE-FLAG value of NO-RESPONSE, or if it had a value of ERROR-RESPONSE and there were no errors encountered while processing the data, then no RESPONSE type message should be sent. Otherwise, a data message should be sent in which the header DATA-TYPE field is set to RESPONSE. The RESPONSE-FLAG field in this header must have a value of either POSITIVE-RESPONSE or NEGATIVE-RESPONSE. A POSITIVE-RESPONSE should be sent if the previously processed message's header specified ALWAYS-RESPONSE and no errors were encountered in processing the data. A NEGATIVE-RESPONSE should be sent when 1) the previously processed message specified ERROR-RESPONSE or ALWAYS-RESPONSE and B. Kelly Expires January 1994 [Page 19] Internet Draft TN3270 Enhancements July 1993 2) some kind of error occurred while processing the data. Please keep in mind that it is normally only the client that will be constructing and sending these RESPONSE messages. A negative response sent by the client to the server is the equivalent of a Unit Check Status [7]. All references to device status and sense codes in this section rely on [7]. The data portion of this RESPONSE message must consist of one byte of binary data. The value of this byte gives a more detailed account of the results of having processed the previously received data message. The possible values for this byte are: For a RESPONSE-FLAG value of POSITIVE-RESPONSE - Value Meaning ----- ------- 0x00 Successful completion (when sent by the client, this is equivalent to "Device End"). For a RESPONSE-FLAG value of NEGATIVE-RESPONSE - Value Meaning ----- ------- 0x00 An invalid 3270 command was received (equivalent to "Command Reject"). 0x01 Printer is not ready (equivalent to "Intervention Required"). 0x02 An illegal 3270 buffer address or order sequence was received (equivalent to "Operation Check"). 0x03 Printer is powered off or not connected (equivalent to "Component Disconnected"). When the server receives any of the above responses, it should pass along the appropriate information to the host application. The appopriate information is determined by whether the server represents an SNA or a non-SNA device. An SNA server should pass along a POSITIVE-RESPONSE from the client as a positive SNA Response Unit to the host application. It should translate a NEGATIVE-RESPONSE from the client into an SNA negative Response Unit in which the Sense Data Indicator bit is on and which contains one of the following sense codes: B. Kelly Expires January 1994 [Page 20] Internet Draft TN3270 Enhancements July 1993 RESPONSE-FLAG Equivalent SNA Sense Code ------------- ---------- -------------- 0x00 Command Reject 0x10030000 0x01 Intervention Required 0x08020000 0x02 Operation Check 0x10050000 0x03 Component Disconnected 0x08310000 A non-SNA server should pass along a POSITIVE-RESPONSE from the client by setting the Device End Status bit on. It should reflect a NEGATIVE-RESPONSE from the client by setting the Unit Check Status Bit on, and setting either the Command Reject, Intervention Required, or Operation Check Sense bit on when responding to the Sense command. In the case of Intervention Required or Component Disconnected being passed by the server to the host application, the host would normally refrain from sending any further data to the printer. If and when the error condition at the client has been resolved, the client must send to the server a data message whose header DATA-TYPE field is set to REQUEST, and whose REQUEST-FLAG is set to ERR-COND-CLEARED. Note that this message has no data portion. Upon receipt of this message, the server should pass along the appropriate information to the host application so that it may resume sending printer output. Again, the form of this information depends on whether the server represents an SNA or a non-SNA device. An SNA server should reflect an ERR-COND-CLEARED to the host application by sending an SNA LUSTAT RU with one of the following sense codes: - if the previous error condition was an Intervention Required, the server should send sense code 0x00010000 - if the previous error condition was Component Disconnected, the server should send sense code 0x082B0000 A non-SNA server should set the corresponding bits in the Ending Status and Sense Condition bytes. 11. The 3270 ATTN Key The 3270 ATTN key is interpreted by many host applications in an SNA environment as an indication that the user wishes to interrupt the execution of the current process. The Telnet Interrupt Process (IP) command was defined expressly for such a purpose, so it seems B. Kelly Expires January 1994 [Page 21] Internet Draft TN3270 Enhancements July 1993 logical to use IP to implement support for the 3270 ATTN key. This requires two things: - TN3270E clients should provide as part of their keyboard mapping a single key or a combination of keys that map to the 3270 ATTN key. When the user presses this key(s), the client should transmit a Telnet IP command to the server. - TN3270E servers should translate the IP command received from a TN3270E client into the appropriate form and pass it along to the host application as an ATTN key. In other words, the server representing an SLU in an SNA session should send a SIGNAL RU to the host application. The ATTN key is not supported in a non-SNA environment; therefore, a TN3270E server representing non-SNA 3270 devices should ignore any Telnet IP commands it receives from a client. 12. The 3270 SYSREQ Key The 3270 SYSREQ key is useful in an SNA environment when the ATTN key is not sufficient to terminate a process. While there are other uses for the SYSREQ key, and while its function is more complicated than what is dealt with in this document, it seems reasonable to implement a subset of the SYSREQ key support that would be beneficial to a large number of users. This subset would be limited to support for the sequence of pressing SYSREQ and typing LOGOFF that many users employ to immediately terminate an SNA session. It is recognized that in the case of host-resident TN3270E servers, essentially the same thing can be accomplished by the user unilaterally closing the Telnet connection, but in the case of servers that do not reside on the host (for example, the commercial TCP-to-SNA gateways) users may wish to terminate the SNA session without closing the Telnet connection. The Telnet Abort Output (AO) command seems the appropriate mechanism for implementing this limited SYSREQ key support, given that in a real SNA session, once the user presses the SYSREQ key, the host application is prevented from sending any more output to the terminal (unless the user presses SYSREQ a second time), but the user's process continues to execute. In order to implement SYSREQ key support, TN3270E clients should provide a key (or combination of keys) that is identified as mapping to the 3270 SYSREQ key. When the user presses this key(s), the client should transmit a Telnet AO command to the server. Upon receipt of the AO command, the TN3270E server should enter what will be loosely termed "suspended mode" for the connection. Any attempt by the host application to send data to the client while the connection is "suspended" should be responded to by the B. Kelly Expires January 1994 [Page 22] Internet Draft TN3270 Enhancements July 1993 server with a negative response, sense code 0x082D, indicating an "LU Busy" condition. The server should not transmit anything to the client on behalf of the host application. While the connection is "suspended," any data messages (except responses) exchanged between the client and server should have the DATA-TYPE flag set to SCS-DATA and the RESPONSE-FLAG set to ALWAYS-RESPONSE. At this point, there are two possible courses of action on the part of the user: - transmit the string LOGOFF (upper or lower case), which will result in the server terminating the SNA session with the host application. In the case of host-based servers, this will also have the effect of closing the Telnet connection. - press the "SYSREQ" key again, which will result in the transmission of another AO to the server. The server should then send to the host application an LUSTAT RU with a value of 0x082B indicating "presentation space integrity lost." The server will then "un-suspend" the Telnet connection to the client, meaning it will allow the host application to once again send data to the client. If, while the Telnet connection is "suspended," the user transmits anything other than the above, the server should respond with the string "COMMAND UNRECOGNIZED" to the client. The server should not send anything to the host application on behalf of the client. The SYSREQ key is not supported in a non-SNA environment; in fact, use of this key on a non-SNA 3270 terminal generally gets the user into difficulties. Therefore, TN3270E servers representing non-SNA 3270 terminals should ignore any Telnet AO commands they receive from a client. 13. 3270 Structured Fields 3270 structured fields provide a much wider range of features than "old-style" 3270 data, such as support for graphics, partitions and IPDS printer data streams. It would be unreasonable to expect all TN3270E clients to support all possible structured field functions, yet there must be a mechanism by which those clients that are capable of supporting some or all structured field functions can indicate their wishes. The design of 3270 structured fields provides a convenient means to convey the level of support (including no support) for the various structured field functions. This mechanism is the Read Partition Query command, which is sent from the host application to the device. The device responds with a Query Reply(s), listing which, if any, structured field functions it supports. B. Kelly Expires January 1994 [Page 23] Internet Draft TN3270 Enhancements July 1993 Therefore, all TN3270E clients must be able to respond to a Read Partition Query command, even if only to indicate that it supports no structured field functions. Note that clients must support both the Read Partition Query (Type 02), and all forms of the Read Partition Query List (Type 03). 14. Examples The following example shows a TN3270E-capable server and a traditional tn3270 client establishing a connection: Server: IAC DO TN3270E Client: IAC WON'T TN3270E Server: IAC DO TERMINAL-TYPE Client: IAC WILL TERMINAL-TYPE Server: IAC SB TERMINAL-TYPE SEND IAC SE Client: IAC SB TERMINAL-TYPE IS IBM-3278-2 IAC SE Server: IAC DO EOR IAC WILL EOR Client: IAC WILL EOR IAC DO EOR Server: IAC DO BINARY IAC WILL BINARY Client: IAC WILL BINARY IAC DO BINARY (3270 data stream is exchanged) The following example shows a TN3270E-capable server and a TN3270E-capable client establishing a generic terminal session: Server: IAC DO TN3270E Client: IAC WILL TN3270E Server: IAC SB TN3270E SEND DEVICE-TYPE IAC SE Client: IAC SB TN3270E DEVICE-TYPE REQUEST IBM-3278-2 IAC SE Server: IAC SB TN3270E DEVICE-TYPE IS IBM-3278-2 CONNECT anyterm IAC SE Client: IAC SB TN3270E FUNCTIONS REQUEST RESPONSES IAC SE Server: IAC SB TN3270E FUNCTIONS IS RESPONSES IAC SE (3270 data stream is exchanged) The following example shows a TN3270E-capable server and a TN3270E-capable client establishing a terminal session where the client requests a specific device-name: Server: IAC DO TN3270E Client: IAC WILL TN3270E Server: IAC SB TN3270E SEND DEVICE-TYPE IAC SE Client: IAC SB TN3270E DEVICE-TYPE REQUEST IBM-3278-5 CONNECT myterm IAC SE Server: IAC SB TN3270E DEVICE-TYPE IS IBM-3278-5 CONNECT myterm IAC SE Client: IAC SB TN3270E FUNCTIONS REQUEST RESPONSES IAC SE Server: IAC SB TN3270E FUNCTIONS IS RESPONSES IAC SE (3270 data stream is exchanged) B. Kelly Expires January 1994 [Page 24] Internet Draft TN3270 Enhancements July 1993 The following example shows a TN3270E-capable server and a TN3270E-capable client attempting to establish a terminal session; multiple attempts are necessary because the device-name initially requested by the client is already in use: Server: IAC DO TN3270E Client: IAC WILL TN3270E Server: IAC SB TN3270E SEND DEVICE-TYPE IAC SE Client: IAC SB TN3270E DEVICE-TYPE REQUEST IBM-3278-5 CONNECT myterm IAC SE Server: IAC SB TN3270E DEVICE-TYPE REJECT REASON DEVICE-IN-USE IAC SE Client: IAC SB TN3270E DEVICE-TYPE REQUEST IBM-3278-2 CONNECT herterm IAC SE Server: IAC SB TN3270E DEVICE-TYPE IS IBM-3278-2 CONNECT herterm IAC SE Client: IAC SB TN3270E FUNCTIONS REQUEST RESPONSES IAC SE Server: IAC SB TN3270E FUNCTIONS IS RESPONSES IAC SE (3270 data stream is exchanged) The following example shows a TN3270E-capable server and a TN3270E-capable client establishing a printer session where the client requests a specific device-name, and where some amount of 3270 function negotiation is required before an agreement is reached: Server: IAC DO TN3270E Client: IAC WILL TN3270E Server: IAC SB TN3270E SEND DEVICE-TYPE IAC SE Client: IAC SB TN3270E DEVICE-TYPE REQUEST IBM-3287-1 CONNECT myprt IAC SE Server: IAC SB TN3270E DEVICE-TYPE IS IBM-3287-1 CONNECT myprt IAC SE Client: IAC SB TN3270E FUNCTIONS REQUEST DATA-STREAM-CTL IAC SE Server: IAC SB TN3270E FUNCTIONS REQUEST DATA-STREAM-CTL RESPONSES IAC SE Client: IAC SB TN3270E FUNCTIONS REQUEST DATA-STREAM-CTL IAC SE Server: IAC SB TN3270E FUNCTIONS IS DATA-STREAM-CTL IAC SE (3270 data stream is exchanged) The following example shows a TN3270E-capable server and a TN3270E-capable client establishing first a generic terminal session, then a printer session where the "partner" printer for the assigned terminal is requested: Server: IAC DO TN3270E Client: IAC WILL TN3270E Server: IAC SB TN3270E SEND DEVICE-TYPE IAC SE Client: IAC SB TN3270E DEVICE-TYPE REQUEST IBM-3278-2 IAC SE Server: IAC SB TN3270E DEVICE-TYPE IS IBM-3278-2 CONNECT termXYZ IAC SE B. Kelly Expires January 1994 [Page 25] Internet Draft TN3270 Enhancements July 1993 Client: IAC SB TN3270E FUNCTIONS REQUEST RESPONSES IAC SE Server: IAC SB TN3270E FUNCTIONS IS RESPONSES IAC SE (3270 data stream is exchanged) . . . . (user decides to request a printer session, so client again connects to Telnet port on server) Server: IAC DO TN3270E Client: IAC WILL TN3270E Server: IAC SB TN3270E SEND DEVICE-TYPE IAC SE Client: IAC SB TN3270E DEVICE-TYPE REQUEST IBM-3287-1 ASSOCIATE termXYZ IAC SE Server: IAC SB TN3270E DEVICE-TYPE IS IBM-3287-1 CONNECT termXYZ's-prt IAC SE Client: IAC SB TN3270E FUNCTIONS REQUEST SCS-CTL-CODES RESPONSES IAC SE Server: IAC SB TN3270E FUNCTIONS IS SCS-CTL-CODES RESPONSES IAC SE (3270 data stream is exchanged) 15. References [1] Rekhter, J., "Telnet 3270 Regime Option", RFC 1041, IBM Corporation, January 1988. [2] VanBokkelen, J., "Telnet Terminal-Type Option", RFC 1091, FTP Software, Inc., February 1989. [3] Postel, J., and J. Reynolds, "Telnet Binary Transmission", RFC 856, USC/Information Sciences Institute, May 1983. [4] Postel, J., "Telnet End of Record Option", RFC 885, USC/ Information Sciences Institute, December 1983. [5] "3270 Information Display System - Data Stream Programmer's Reference", publication number GA24-0059, IBM Corporation. [6] "Systems Network Architecture - Network Product Formats", publication number LY43-0081, IBM Corporation. [7] "3174 Establishment Controller Functional Description", publication number GA23-0218, IBM Corporation. 16. Author's Note Portions of this document were drawn from the following sources: - A White Paper written by Owen Reddecliffe, WRQ Corporation, October 1991. B. Kelly Expires January 1994 [Page 26] Internet Draft TN3270 Enhancements July 1993 - Experimental work on the part of Cleve Graves and Michelle Angel, OpenConnect Systems, 1992 - 1993. - Discussions at the March 1993 IETF meeting. - Discussions on the "TN3270E" list, Spring/Summer 1993. 17. Author's Address Bill Kelly Division of University Computing 144 Parker Hall Auburn, AL 36849 Phone: (205) 844-4512 Email: kellywh@mail.auburn.edu B. Kelly Expires January 1994 [Page 27]